| |

| |
| HOME | BOOKS | DOWNLOAD | NEWS | AFFILIATES | EXPERT STORES | SUPPORT | SITE MAP | CONTACT |
| |

Search wrox.com

| |

Book Details

Sample Chapter (PDF)

Download Acrobat
Reader for free

| |

| |

Buy this book from:

-- not selected --

Amazon.com

Amazon.ca

Amazon.co.uk

Amazon.de

Computer Manuals

SoftPro (US)

Wrox Expert Stores

| |

| |

Authors:
Kevin Williams
Jeni Tennison
Scott Bonneau

ISBN number:
1-861007-68-X
Published:
February 2003
Pages: 328
Price:
US$ 39.99

| |

XML Design Handbook

Summary of Contents

Introduction
Chapter 01: Architecture Strategies
Chapter 02: Basic Document Design
Chapter 03: XML Schema Design
Chapter 04: Parsing Strategies
Chapter 05: XSLT Strategies
Chapter 06: XML Storage and Archiving
Chapter 07: Presentation Strategies

Table of Contents

Introduction

What's Covered in this Book?

Who is this Book For?

Code Conventions

Tell Us What You Think

Downloading the Sample Code

Errata

Chapter 1: Architecture Strategies

1.1 Example Scenario

1.2 Systems for Analyzing and Transforming Data

1.2.1 Use an XML-based API to Provide a Common and Flexible Data Representation
Among Software Components

1.2.2 Use XSLT for Transforming XML Markup

1.2.3 Use an XML-based API to Extend and Reuse Existing Components

1.2.4 Use an XML-based Network Protocol to Maximize Component Reusability
and Availability

1.3 Systems for Managing Data

1.3.1 Use XML to Represent Meta Data About the Items Being Managed

1.4 Systems for Experiencing and Controlling with Data

1.4.1 Use XML and XSLT to Support Experiences for Multiple Modalities

1.4.2 Use XML Standards-based Languages According to the Industry of the
Device or System being Controlled

1.5 Summary

Chapter 2: Basic Document Design

2.1 Narrative and Data‑oriented Document Structures

2.1.1 Use Data‑oriented Document Structures to Model Well‑structured Data

2.1.2 Use Narrative‑style Document Structures to Augment Plain‑text Data

2.2 Building Blocks: Attributes, Elements, and Character Data

2.2.1 For Narrative-Style Documents, Understand "The Rule"

2.2.2 Understand the Differentiating Characteristics of Elements and Attributes

2.2.2.1 Elements are More Expensive than Attributes, Both in Space and in Time

2.2.2.1.1 Spatial Issues

2.2.2.1.2 Parsing Time

2.2.2.2 Elements are more Flexible than Attributes

2.2.2.3 Character Data versus Attributes

2.2.3 Favor Attributes for Data that Identifies the Element

2.2.4 Avoid Attributes for Data where Order is Important

2.3 General Data Modeling Pitfalls

2.3.1 Avoid Designing for a Specific Platform or Parser Implementation
Wherever Possible

2.3.2 The Underlying Data Model often isn't the Best Choice as an XML Encoding

2.3.3 Avoid Over‑stuffing your Documents

2.3.4 Avoid Pointer‑heavy Document Structures

2.4 Conclusion

Chapter 3: XML Schema Design

3.1 Advantages of XML Schemas over DTDs

3.2 Basic Ground Rules

3.2.1 The Role of Validation ??? Checking Structures of Documents

3.2.2 To Validate or not to Validate?

3.2.2.1 Always Validate Documents during Development and Testing

3.2.2.2 Turn Validation Off only if you can Trust the Source

3.2.2.3 Check how Documents are Created

3.2.2.4 The more Complex a Schema, the Greater the Risk

3.2.2.5 Don't Validate Documents that You Create and Receive

3.2.2.6 Validation is a Lower Cost with Batch Processes

3.2.2.7 Summary of Validation Issues

3.2.3 Flexibility of Schemas Should Reflect Predictability of Data

3.2.4 Follow Naming Conventions

3.2.5 Create Consistent, Ordered Structures

3.3 Same Constraints, Different Representations

3.3.1 Do not Always Mirror Document Structures

3.3.1.1 Look for Reuse when you have Repeating Structures

3.3.1.2 Deeply Nested Complex Types are not Flexible

3.3.1.3 Mirror Document Structures only when Writing Small Rigid Schemas

3.4 How and Why to Reuse

3.4.1 Reuse Mechanisms

3.4.1.1 Globally Declared Elements ??? Reusing Elements and their Content Model by Reference

3.4.1.1.1 Occurrence Constraints cannot be used on Global Declarations

3.4.1.1.2 Globally Declared Elements can be used as the Root Element of a Schema

3.4.1.2 Complex Type Definitions ??? for Class‑like Definitions

3.4.1.2.1 You Cannot Validate a Fragment against a Complex Type (as you could with Globally
Declared Elements)

3.4.1.2.2 Complex Types are Associated with Containing Elements

3.4.1.3 Named Model Groups as Building Blocks for Content Models

3.4.1.3.1 You Cannot Validate a Fragment against a Named Model Group (as you could with
Globally Declared Elements)

3.4.1.3.2 You can Create Repeating Groups with Named Model Groups

3.4.1.3.3 Avoid Overuse of Named Complex Types

3.5 Namespaces

3.5.1 The Three Uses of Namespace in XML Schemas

3.5.2 Distinguish between your Elements, Attributes, and Types, and those of
XML Schema

3.5.3 Introducing Namespaces into your Markup

3.5.4 Creating Vocabularies that Belong to a Namespace

3.5.5 Requiring all Elements and Attributes to be Qualified

3.6 Models and Issues for Local Versus Global Declarations

3.6.1 Russian Doll Design

3.6.2 Salami Slice Design

3.6.3 Comparing the Russian Doll and Salami Slice Designs

3.6.3.1 The Salami Slice Design Facilitates Individual Component Reuse; the
Russian Doll Design does not

3.6.3.2 Components of the Russian Doll Design have Localized Scope; Components of the
Salami Slice Design have Global Scope

3.6.3.3 Components of the Russian Doll Design are Decoupled; Components of the
Salami Slice Design are Coupled

3.6.3.4 The Russian Doll Design Allows only One Document Element to be used;
Salami Slice Design offers all Globally Defined Elements

3.6.3.5 The Salami Slice Design Facilitates Hiding of Namespace Complexities; the
Russian Doll Design does not

3.6.3.6 The Salami Slice Approach is more Similar (than the Russian Doll Design) to DTDs

3.6.3.7 On Balance

3.6.4 The Venetian Blind Model

3.6.4.1 Venetian Blind Model Allows Reuse of Content Models without Globally
Defining Each Element

3.6.4.2 Venetian Blind Model Keeps Related Information Together without the Deeply
Nested Complex Structures of the Russian Doll Design

3.6.4.3 Venetian Blind Model Hides Namespace Complexities, as Child Elements are
Declared Locally

3.6.4.4 Venetian Blind Model Allows for More Compact Schemas

3.6.5 Avoid Overuse of Named Complex Types in the Venetian Blind Model

3.6.5.1 Model Complex Types on Real World Entities

3.6.5.2 Problems with Extending and Restricting Named Complex Types

3.6.5.3 You can Associate only One Element with One Type Definition

3.6.6 The Alternative: Venetian Blind and Named Model Groups

3.7 Tightening up your Schemas

3.7.1 Adding Constraints

3.7.1.1 Use Occurrence Constraints to Indicate the Number of Times an Element may Appear

3.7.1.2 Use Value Constraints for Default or Fixed Values

3.7.2 Avoid Over‑dependence on Built‑in Datatypes

3.7.2.1 How to Add Restrictions to Simple Types

3.7.2.2 Limit Allowable Lengths for Fields that use Strings

3.7.2.3 Consider Limiting the Range of Allowable Values in Numeric Fields

3.7.2.4 Restrict Integer rather than Platform‑ Programming‑Oriented Types when Working
with Numbers

3.7.2.5 Provide Enumerated Values for a Fixed Set of Options

3.7.2.6 Use Regular Expressions to Control Allowable Values that have Patterns

3.7.3 Representing Null Values in XML Instance Documents

3.7.3.1 The Difference Between a Null and an Empty Value

3.7.3.2 Solving the Problem by Using xsi:nil

3.7.3.3 Using xsd:union to Create Null Values for Attributes

3.7.3.4 Saying Why There is No Value with Custom Attributes

3.8 Summary

Chapter 4: Parsing Strategies

4.1 Before You Start

4.1.1 In General, the Intended use of the Document Should Drive your
Parsing Strategy

4.1.2 Learn and Understand the Standard Parsing APIs: DOM and SAX

4.1.2.1 DOM

4.1.2.2 SAX

4.2 Choosing between DOM and SAX: Which and When?

4.2.1 Avoid DOM when the XML is just a Storage or Encoding Mechanism

4.2.2 Favor DOM when the XML is the Primary Representation of the Document

4.2.3 Avoid DOM when You're Only Interested in Parts of the Document

4.2.4 Choose your Parsing Strategy Carefully when Dealing with
Pointer‑heavy Documents

4.2.5 When to Favor a Pull Parser

4.2.6 Consider using a Hybrid Approach when neither SAX nor DOM Provides
the Necessary Functionality

4.3 Implementation Patterns

4.3.1 With SAX, use a Context Stack when Parsing Deeply Nested Documents

4.3.2 When using SAX in Java, Consider using an Inner Class to do the Parsing for
an XML‑deserializable Class

4.3.3 In C#, Consider using the XmlSerializer Class and XML Serialization
Attributes for Simple Serialization

4.3.4 When using DOM as the Primary Representation of a Document, Consider
Wrapping it for Type‑safety

4.4 Conclusion

Chapter 5: XSLT Strategies

5.1 A Quick XSLT Example

5.2 XSLT Status

5.3 Using the XSLT Processing Model

5.3.1 Use Push and Pull Appropriately

5.3.1.1 Apply Templates to Only the Nodes that You Want to Process

5.3.1.2 Process Mixed Content Using Templates Rather than xsl:for‑each

5.3.2 Break up your Transformations

5.3.3 Use XML Lookup Tables Rather than Procedural Code

5.3.4 Using Recursion

5.3.4.1 Use a Tail‑recursive Algorithm when Possible

5.3.4.2 Use a Divide and Conquer Algorithm if Speed is Important

5.3.5 Avoiding Pitfalls

5.3.5.1 XML and HTML are not Text

5.3.5.2 Avoid the Text Output Method

5.3.5.3 Avoid Disable-output-escaping

5.3.5.4 Use Attribute Value Templates

5.3.5.5 Be Namespace‑aware

5.3.5.6 Avoid Using Extension Functions Written in Scripting Languages

5.3.5.7 Consider Using ESXLT Modules for Extensions

5.4 Speeding up Your Stylesheet

5.4.1 Minimize Node Visits

5.4.1.1 Use Keys to Speed Up Multiple Searches

5.4.1.2 Use Keys to Speed up Grouping

5.4.1.3 Consider Using position() Rather than xsl:number

5.4.1.4 Avoid the "Long" Axes

5.4.2 Avoid Node Creation

5.4.2.1 Use Small Documents

5.4.2.2 Strip Unnecessary Whitespace

5.4.2.3 Avoid Creating Result Tree Fragments

5.5 Increasing Modularity and Reusability

5.5.1 Parameterize your Stylesheet

5.5.2 Import General Stylesheets into Specific Ones

5.5.3 Use Modes on your Templates

5.6 References

5.6.1 XSLT Processors

5.6.2 Recommended Reading

Chapter 6: XML Storage and Archiving

6.1 Storing XML

6.1.1 Problems with Creating Pure XML Storage Layers

6.1.1.1 Searching a Pure XML Storage layer is Slow

6.1.1.2 Document Aggregation is Difficult

6.1.1.3 Document Manipulation is Inefficient

6.1.1.4 Solving the Problems with Indexing

6.1.2 Native XML databases

6.1.3 Relational Repositories with an XML Wrapper Layer

6.1.4 Hybrid Repositories

6.1.4.1 Storing Complete XML Documents and Relational Data

6.1.4.2 Storing XML Document Fragments and Relational Data

6.1.4.3 Comparing Hybrid Approaches

6.2 Storage System Design Issues

6.2.1 Problems with Storing XML Documents as Received

6.2.2 Shaping the Storage to Fit the Task

6.2.3 Multiple Repositories for Multiple Purposes

6.3 Problems with XML Decomposition

6.3.1 Unnecessary Processing

6.3.2 Difficulty Handling Unstructured Data

6.3.3 The Solution: Hybrid XML-Relational Modeling

6.3.3.1 Hybrid Storage for Narrative Documents

6.3.3.2 Hybrid Storage for Data-centric Documents

6.4 Archiving in XML

6.4.1 Issues with Pure XML Archives

6.4.1.1 Retrieval of Archived Information

6.4.1.2 Recall of Information across Archived Documents

6.4.2 Archiving Document Indexes

6.4.3 Archiving of Summary Information

6.4.4 Archiving Other Information

6.5 Summary

Chapter 7: Presentation Strategies

7.1 Example Scenario

7.2 Configurability

7.2.1 Role‑based Configurability

7.2.1.1 Develop Role‑specific Stylesheets and Run from a Common Framework

7.2.2 Device‑dependent Configurability

7.2.2.1 Develop Device‑specific Stylesheets to be used in a Device‑Independent Framework

7.2.3 Personalization

7.2.3.1 Pass Personalization Parameters into your Stylesheets

7.3 Performance

7.3.1.1 Anticipate Presentation Needs by having Information Ready to Deliver,
or Pre-parse XML and XSLT stylesheets

7.3.1.2 Use Runtime Styling when Data Accuracy is Important

7.3.1.3 For Rapid Development, Perform the XSL Transforms at the Client

7.3.1.4 For Simple Styling Requirements, use Cascading Stylesheets (CSS)

7.4 Use of Rich Media

7.4.1 Synchronized Media

7.4.1.1 Determine how the Client will Playback the Rich Media Presentation so as to Decide
on the Format

7.4.1.1.1 For Playing Synchronized Rich Media in a SMIL 2.0‑compliant Media Player or Plug‑in,
Represent your Presentation in SMIL

7.4.1.1.2 If your Primary Client Environment is IE 6.0 and higher, you can Represent your
Presentation in XHTML+SMIL

7.5 Cross‑Platform Support

7.5.1.1 Use the JAXP and TRaX API for Cross-Platform Support

7.6 Working with Third‑party and Legacy Data or Software

7.6.1.1 Use XSL to Convert Between Older and Newer Formats

7.7 Maintainability and Extensibility

7.7.1.1 Break Units down into Smaller, Less Complicated Pieces

7.8 Summary

Appendix A: Parser Performance

Implementation does Matter

The Examples

The Parser Implementations

Running the examples

The Directory Structure

Using the Predefined Batch Files

Plugging in your Favorite JAXP Implementation to the Examples

The Test Environment

How the Tests Were Conducted

Examples From Chapter 2

Performance of Elements vs. Attributes (Section 2.2.2.1.1)

SAX

Notes

DOM

Notes

Books (Section 2.2.3)

Notes

Examples from Chapter 4

Order Digests (Section 4.2.1)

SAX

Notes

DOM

Notes

Arithmetic Expressions (Section 4.2.2)

Notes

DOM Adapter (Section 4.2.6)

Notes

File System DOM (Section 4.3.4)

Notes

Conclusion

Index

A Guide to the Index

The sample chapter PDF's used on our site are produced in Adobe Acrobat version 5.0 format. The latest version of Adobe Acrobat Reader can be downloaded from http://www.adobe.com/products/acrobat/readstep2.html.

| |
Wrox®  Programmer to ProgrammerTM    The one-stop source of information for programmers

| |

BOOKS | WROXDIRECT | WROXBASE | ASPTODAY | C#TODAY  | P2P FORUMS | DISTRIBUTORS | WRITE FOR US | ABOUT
WROX INDIA | WROX FRANCE | WROX KOREA | WROX ACADEMIC  | TERMS & CONDITIONS | PRIVACY | JOBS @ WROX

| |

©2002 Wrox Press UK and USA.     Contact: [email-masked]     Created: 18 Apr 2003 at 02:46:58